Business Analyst Community & Resources | Modern Analyst

What is a Use Case Diagram?

Chris Adams — Sun, 11 Sep 2022 23:21:00 GMT

[Be the first to post an answer to this question!]

Why bother with identifying use cases? Why not jump straight to process flows?

Chris Adams — Thu, 07 Oct 2021 16:15:00 GMT

Whether documenting business processes or systems processes, use cases and process flows can both be valuable tools.

A use case description textually describes the main success scenarios of a process as well as the major alternate scenarios and exception scenarios. Process flows do the same thing, though in graphical form. A process flow documents the step by step activities of the main success scenario. Decision points (often shown as diamond shapes) show where the main scenario branches off into alternate scenarios.

How do you ensure that your use case model is effective?

Chris Adams — Fri, 12 Mar 2021 17:38:00 GMT

Use case models include actors and use cases. An effective model must identify both comprehensively. Yet, analysts usually fail to identify all of the relevant actors.

To solve this problem, I like to recommend an approach that maintains a separate use case diagram and actor diagram. Then, the actors from the actor diagram can incrementally be added to the use case diagram as the use case diagram evolves.

Why are modeling techniques so important to Business Analysts, and how do you choose the right ones for your project?

Chris Adams — Mon, 08 Jun 2020 17:30:00 GMT

Grouping related items (whether requirements, ideas, business processes, etc.) into a diagram or model is just a way of forming them into recognizable and (hopefully!) familiar patterns. And the short-term memory limit is much less constraining if people are asked to remember and absorb a few different patterns as opposed to dozens of individual bits of information.

In which document do you include the Class Diagram (business requirements, functional requirements, software specification document)?

sonavi — Mon, 12 Nov 2018 16:20:00 GMT

Just like any other diagram, the Class Diagram is just a tool at the disposal of the analyst. In the absence of a set process, it is at the analyst’s discretion to determine when to use a class diagram. Therefore, in which analysis artifact/document a class diagram should be included depends on its use.

Would you use a sequence diagram or an activity diagram to model a process flow that has lot of conditional flows and concurrent processing?

Chris Adams — Sun, 08 Jul 2018 19:10:00 GMT

Modeling of processes that contain a lot of conditional flows and concurrent processing is typically done using an activity diagram. Showing decision points with multiple outcomes and parallel processes is not only easy to accommodate using the standard UML activity diagram, it is more readily understood by an audience that doesn't have a detailed understand of the UML notation. It's intuitive.

What are the benefits of a developing a business entity model early in the analysis process?

Chris Adams — Sun, 10 Jul 2016 21:00:00 GMT

There are numerous benefits to developing a business entity model (also called a logical data model), early in the analysis process. To understand these benefits, the information captured in the business entity model needs to be understood.

What is a Use Case Realization?

Chris Adams — Sat, 08 Aug 2015 16:31:00 GMT

A use case realization provides a construct to organize artifacts which shown how the physical design of a system supports the logical business behavior outlined by a used case. Each use case realization will define the physical design in terms of classes and collaborating objects which support the use case. Therefore, each use case realization typically is made up of a class diagram and a number of interaction diagrams, most commonly sequence diagrams, showing the collaboration or interaction between physical objects.

What is RML (Requirements Modeling Language)?

Chris Adams — Sun, 10 May 2015 23:02:00 GMT

Requirements Modeling language is a collection of diagrams used to model software from the business analysis or product management perspective.

What is the difference between a business use case and a system use case?

Chris Adams — Sun, 09 Nov 2014 17:00:00 GMT

A business use case describes a customer, business worker, or other interested party and how they interact with the business in order to achieve an expected outcome.

A system use case describes how an actor (customer, business worker, or even another system) interacts with a specific system.

What is the difference between a use case alternative flow and an exception flow?

cadams — Sun, 12 Oct 2014 06:13:00 GMT

A use case specification describes the functionality of a system in terms of a sequence of user-system interactions. The main flow of events describes a single path through the system. It represents the most common way that the use case plays out successfully and contains the most common sequence of user-system interactions. Other scenarios or paths through the system are described in alternative flows and exception flows. So what is the difference between and alternative flow and an exception flow?

List the UML Diagrams available to the business analyst?

Chris Adams — Sun, 08 Sep 2013 22:50:00 GMT

UML 2.0 contains 13 different diagrams (up from 9 in the previous versions of UML) that can be grouped into 3 different categories. These categories are:

1. Structure Diagrams

2. Behavior Diagrams

3. Interaction Diagrams

There are 6 Structure Diagrams which include:

-Class Diagram

-Object Diagram

-Component Diagram

-Composite Structure Diagram

-Package Diagram

-Deployment Diagram

There are 3 Behavior Diagrams which include:

-Use Case Diagram

-Activity Diagram

-State Machine Diagram

There are 4 Interaction Diagrams which include:

-Sequence Diagram

-Communication Diagram

-Timing Diagram

-Interaction Overview Diagram

When do you use the Use Case relationship Extend versus Include?

Chris Adams — Mon, 12 Nov 2012 01:22:00 GMT

The UML Use Case relationships Include and Extend remain a point of confusion for many business analysts.

Both the include relationship and the extend relationship build off of a base use case. In theory, a business analyst could write a base use case and never use the include or extend relationships. However, as use cases become larger and more complex with numerous alternate flows choosing to use include or extend can reduce the complexity of the base use case and improve the overall understandability of the use case model.

So when would a business analyst choose to include another use case?

The most predominant reason to create an included use case is for reuse. The include relationship can be used to segment out a series of contiguous steps which can then be reused by other use case. The including use case can often be a standalone use case of its own which is initiated directly by an actor, but it doesn’t have to be. However, it is a required step in the use can which includes it, and it is included at a single specific location in the base use case. This means that the base use case isn’t complete without its included use cases. Additional, based on the direction of the association arrow, you can see that the base use case has knowledge of the existence of the included use case. However, the included use case doesn’t know about the use cases that include it.

When would a business analyst use and extends relationship?

The extend relationship is used to segment out conditional or optional functionality, and is comparable to an alternate flow. Often while writing use cases alternate flows can become quite complex, or can span additional subflows. This is when it may make sense to extract the alternate flow as a separate use case which extends the base use case. This is called an extension use case. Of course this is only advantageous if the flow to be extracted is reasonable self-contained from the main flow. If the two are too intermingled then the extension use case will be difficult to understand.

The extension use case is aware of and can modify the behavior of the base use case. However, the base use case has no knowledge of the extension use case. An extension use case can have one or several behavioral sequences called segments that modify the base use case. Each segment augments the base use case at a specific extension point noted in the base use case. Additionally, the condition under which the the base use case is augmented is defined by the extension use case.

To summarize:

Include Relationship

Use to segment out a reusable series of steps

Base use case is incomplete without the included use case (use include for required behavior)

Include use case isn’t aware of the use cases that use it (this becomes even more important from a system coding perspective)

Extend Relationship

Similar to an alternate flow, it contains optional or conditional behavior

An extension use case is incomplete without the base use case

Extension use cases are often used for behavior that will be implemented at a later time

If enhancing an existing system, using Extend can help separate new functionality from old

What is OOAD?

Chris Adams — Sun, 09 Sep 2012 16:25:00 GMT

The acronym OOAD stands for Object Oriented Analysis and Design. OOAD is a software engineering approach that models and designs a system as a group of interacting objects. Object is the term used to describe some entity or “thing” of interest. These objects are typically modeled after real world entities or concepts. For the business analyst, these would be the real-world entities that arise within the business (invoice, product, contract, etc).

Objects have attributes which can be set to specific values. This defines the state of the object. Objects also have methods or functions which define their behavior.

Here is a quick example for illustrative purposes. Consider the real world object “Car”. Our car has attributes that can be defined with specific values such as,

make = ford
model = escape
year = 2002
color = green
maximum speed = 130 mph
current speed = 50 mph
ideal tire pressure = 35 psi
current tire pressure = 31 psi
remaining fuel = 12 gallons

Each of these attributes define the “state” of the vehicle. They describe the car as it is at some point in time. Additionally, the car has certain “behaviors” such as

accelerate ()
decelerate ()
refuel ()
fill tires ()

Each of these behaviors of the real world object can be represented as a method of the object when designing the system (methods are also known as a functions in some programming languages). These methods can change the values of the attributes causing a change in state.

OOAD is comprised of two parts:

(1) object oriented analysis

(2) object oriented design

Models of different types can be created to reflect the static structure, dynamic behavior, and run-time deployment of the collaborating objects of a system.

During the object-oriented analysis (OOA) phase object-modeling techniques are used to analyze the functional requirements for a system and create models which reflect the logical design of the system. During the object-oriented design (OOD) phase of the system, models are elaborated upon to include implementation specific details that show how the physical design of the system will come together. OOA focuses on what the system does (its static structure and behavior), OOD on how the system does it (it’s run-time implementation).

What is the difference between a Pool and a Swimlane?

Chris Adams — Sun, 08 May 2011 02:06:00 GMT

A “swimlane” is a generic industry term used to describe the grouping of common activities in a process diagram into labeled rectangular area.

Two of the more common standards for process diagrams are the UML Activity Diagram and the BPMN Business Process Diagram (aka Swimlane Diagram).

In UML, the generic “swimlane” is represented by a concept that is called an Activity Partition. The UML 2.0 specification describes an activity partition as a “kind of activity group for identifying actions that have some characteristic in common.” Activity Partitions can be further divided into Activity Sub-partitions. There is really no difference between an Activity Partition and an Activity Sub-Partition other than the level at which the group activities based on a common set of characteristics.

In BPMN, the generic term “swimlane” is represented by either a Pool or a Lane in the swimlane diagram. A Pool is a graphical representation of a participant within the business process diagram. Pools can represent different businesses, a generic business partner (like a supplier, manufacturer, or buyer), or be more granular if modeling a single business without external dependencies. Additionally, a Pool may reference a process and show the internal details (white box), or it may have no internal details (black box). A Pool acts as a container for the activities and sequence flows between activities.

Lanes are mentioned in the BPMN specification as being used to organize and categorize activities within a pool. However, the precise meaning of a lane or its appropriate scope is left up to the modeler, as the specification is silent in this area.

So, besides the fact that a Lane is used to subdivide a Pool, what is ultimately the difference between the two? Sequence flows can cross Lanes between activities but they cannot cross Pools. Only messages can pass between Pools. This is by design and is a major benefit of the BPMN notation. Messages indicate transfer of information within a conversation between two parties. These are points of risk within the business process and deserve extra attention. Both minimizing points of communication as well as ensuring clear communications take place help reduce process risk.

Additionally, participants of one pull have no control over the completion of activities that may occur in another pool. Whereas, activities divided between lanes can sometimes be performed by the same person, even if they that person is performing a different role (wearing multiple hats).

What is a navigable association in UML?

Chris Adams — Mon, 11 Apr 2011 01:36:00 GMT

Associations are relationships between classes in a UML Class Diagram. They are represented by a solid line between classes. Associations are typically named using a verb or verb phrase which reflects the real world problem domain.

The normal kind of association is bidirectional by default. This means that if an association exists between two classes, then both objects know about each other. However, when creating a UML class diagram it is possible to use a navigable association between two classes. This is shown by adding an arrowhead at one end of the association. If “A” is the source class and “B” is the target class, the arrowhead would be placed on the “B” side of the association. A navigable association of this type means that at runtime object “A” knows about object “B”, but object “B” has no knowledge of or visibility into object “A”.

What is a Swimlane Diagram?

Chris Adams — Sat, 09 Apr 2011 22:42:00 GMT

A swimlane diagram (also sometime called a cross-functional diagram) documents the steps or activities of a process flow or workflow. More specifically, a swimlane diagram groups these activities into swimlanes which are horizontal or vertical columns that contain all of the activities which fit into the category represented by that swimlane. Swimlanes can represent many categories of information such as actors which perform the activities (i.e., role or department), the stage of the process in which the activity takes place, or whatever else the creator of the document feels should be emphasized and communicated by the swimlane diagram. The term swimlane was adopted due to the visual similarity between the horizontal rows of the diagram to that of the swimlanes found within a swiming pool.

A process flow or workflow diagram does not have to use swimlanes. However, since swimlanes communicate additional information about who performs the activity or when it takes place, it’s typically a preferred best practice to include them. Similarly, a swimlane diagram can use only one set of swimlanes (either vertical swimlanes or horizontal swimlanes). In BPMN standards, a process flow is typically shown flowing from left to right. If only one set of swimlanes is used, horizontal swimlanes are most commonly used to group activities. In the UML standard, the activity diagram flows from top to bottom and veritcal swimlanes are most commonly used.

One of the more common choices used by creators of swimlane diagrams is to define the roles which perform each activity within horizontal swimlanes and define the process stages in which the activity occurs within vertical swimlanes.

What is a Communication Diagram?

Chris Adams — Fri, 08 Oct 2010 00:52:00 GMT

A UML 2.0 Communication Diagram models the objects or parts of a system, the interactions (or messages) between them, and the sequence in which these interactions occur. There are a lot of similarities between communication diagrams and sequence diagrams in terms of the information they show, but because of how each diagram presents the information, one diagram may be better at conveying or emphasizing specific information over the other.

Communication diagrams use a free-form arrangement of objects or parts of a system. This can be compared to how classes and objects are laid out in UML class and object diagrams. Then the interactions between the objects or parts of the system are show and labeled to indicate the chronological sequence in which they occur. The free-form arrangement of objects lends itself wekk to showing the sequenced interactions in a more compact space, allowing the analyst to place objects that have the highest number of interactions with each other near one another. This is the advantage of the communication diagram over the sequence diagram. While showing nearly all of the same information as a sequence diagram, the communication diagram can, at a glance, place a strong emphasize on which objects are interacting with one another

While communication diagrams are formally intended to show system objects and the interactions between them, many analysts choose to create them at a higher level of abstraction. Instead of showing the interactions between objects of a system, larger parts of a system may be represented such as the interaction between web methods, web services, or entire systems.

By using the communication diagram in this way, it shows some similarities to a system context diagram. The primary differences between the two are that a system context diagram places a focus on a single system in context along with which actors and systems outside of the scope of the system interact with it. Additionally, a system context diagram does not show the sequence of interactions.

What are the similarities and differences between a UML Class Diagram and Object Diagram?

Chris Adams — Sun, 09 May 2010 20:37:00 GMT

Class Diagrams and Object Diagrams use almost identical notations. Both represent a static view of a system, however Object Diagrams represent a snapshot in time, whereas Class Diagrams are not time dependent and are an abstract view of the types of objects that may exist within a system, the relationships between them, and how and when one type of object can exist in relationship to another. Since Object Diagrams represent specific object instances that exist at a single point in time, they are sometimes called Instance Diagrams.

A few notable differences in the notation and rules used to represent Class and Object Diagrams are:

Class Diagrams represent each class via a rectangle and display up to 3 types of information; the class name (not underlined), its attributes, and its operations. The Object Diagram also uses a rectangle to represent an object instance, however the object name is underlined and lists the name of the object followed by a colon and then the class name which describes its type (e.g. Joe: Student, where Joe is the name of the object instance and Student is class). Additionally the Object Diagram will list an object's attributes, but it will also list the value of that attribute at that point in time (e.g. SSN = 555-55-5555).

Class Diagrams enforce multiplicity rules between associated classes. For example, a Class Diagram may display an association between a Car and Passengers. The Class Diagram would show a single rectangle to represent the class car and a single rectangle to represent the class passenger, but display multiplicities stating that each car may have 1..4 passengers. An Object Diagram being a snapshot in time would show a rectangle for the Car and up to 4 separate rectangles, one for each passenger that exists at that movement in time.

Many of the constraints or association types that exist in a class diagram have no relevance in an object diagram. Multiplicities in a class diagram may constrain the number of passengers in a car to 4, but this rule would be enforced within the code itself such that a 5th passenger object could never be created. Therefore, multiplicities are not shown within an object diagram. Only the actual numbers of objects that exist at that moment in time are shown. Similarly, other constraints such as "at least one passenger be of type driver" could also be captured and displayed in a class diagram but would not be shown in an object diagram since these rules are enforced within the actual code.

What is the difference between a Primary and Secondary Actor in Use Case Modeling?

Chris Adams — Sat, 09 May 2009 22:10:00 GMT

What is an Activity Diagram and what is its purpose?

Chris Adams — Sat, 05 Jul 2008 20:05:00 GMT

An Activity Diagram is a behavioral diagram that shows the flow or sequence of activities through a system. The terms activity diagram and process flow are often used interchangeably. However, the term activity diagram is typically more restrictive as it refers to one of thirteen standard Unified Model Language (UML) diagrams. Activity Diagrams are one of the most commonly used diagrams since its notation and origin are based on the widely known flowchart notation.

What are the basic elements of an Activity Diagram?

Chris Adams — Sat, 05 Jul 2008 19:42:00 GMT

UML defines a specific notation and set of rules for creating Activity Diagrams. The following are the most commonly used elements:

Initial Node - The initial node represents the starting point of the activity diagram.
Activity Final Node - The activity final node represents the termination point of the activity.
Action Node - An action node is a type of activity node that represents a single action or behavior of the activity being modeled.
Activity Edge - An activity edge creates a directed connection between two activity nodes. It represents the path that a token can take between two activity nodes.
Decision - A decision has one flow entering and several exiting. The exiting flows each have a condition that must be met in order to traverse the flow.
Merge - A merge has several flows entering and one exiting. The merge denotes that multiple parallel flows are merging at a single point. Only one flow must reach the merge point in order to continue to traverse the flow to the next activity.
Fork - A fork has one flow entering and several exiting. A fork denotes that several processes are occurring in parallel.
Join - A join has several flows entering it and one exiting it. A join denotes that multiple parallel flows are merging at a single point. All flows going into the join must be completed before the next activity can start.

There are others, but these eight symbols constitute the basic notation used by nearly every Activity Diagram.

What is use case generalization?

everest — Tue, 27 May 2008 18:10:00 GMT

In the context of use case modeling the use case generalization refers to the relationship which can exist between two use cases and which shows that one use case (child) inherits the structure, behavior, and relationships of another actor (parent). The child use case is also referred to the more specialized use case while the parent is also referred to as the more abstract use case of the relationship.

For those of you familiar with object oriented concepts: use cases in UML are classes and the generalization is simply the inheritance relationship between two use cases by which one use case inherits all the properties and relationships of another use case.

You can use the generalization relationship when you find two or more use cases which have common behavior/logic. In this instance, you can describe the common parts in a separate use case (the parent) which then is specialized into two or more specialized child use cases.

Example:

If you are creating a payment system which allows students of a training provider to pay for courses both on-line and by phone, there will many things in common between the two scenarios: specifying personal info, specifying payment info, etc. However, there would also be differences between the two. So, the best way to accomplish this is to create one use case (the parent) which contains the common behavior and then create two specialized child use cases which inherit from the parent and which contain the differences specific to registering on-line vs. by phone.

What is actor generalization?

everest — Tue, 27 May 2008 17:18:00 GMT

In the context of use case modeling the actor generalization refers to the relationship which can exist between two actors in a use case diagram and which shows that one actor (descendant) inherits the role and properties of another actor (ancestor). The generalization relationship also implies that the descendant actor can use all the use cases that have been defined for its ancestor.

For those of you familiar with object oriented concepts: actors in UML are classes and the generalization is simply the inheritance relationship between two actors by which one actor inherits all the properties and relationships of another actor.

Example 1:

When it comes to air travel, both a "Business Traveler" and a "Tourist" are "Passengers". The fact that they are passengers allow them to have common behavior such as "Buy Ticket" but the fact that they are separate actors implies they can also have differences. The "Business Traveler" might be able to "Redeem Business Miles" while the "Tourist" cannot.

Example 2:

Another scenario often found in many systems is when the system administrator, who gets additional functionality, is actually one of the normal users. So let's say that the system is an accounting system with the main actor being "Accountant" and with another actor called "Administrator". In our scenarios the Administrator should be able to perform all the normal accounting functions in addition to his/her administrator role.

The way to model this would be to show relationships between the Administrator actor and all the admin only use cases, then show all the accounting specific use cases related to the "Accountant" actor. And now, the only other thing you need to do for the "Administrator" to have access to the accounting features is to use the generalization relationship between the "Accountant" and the "Administrator" with the Administrator actor (descendant) inheriting from the Accountant actor (the ancestor).

Is it the job of a business analyst or systems analyst to draw the class diagram?

ModernAnalyst.com — Sat, 17 May 2008 06:00:00 GMT

It depends, it depends, and it depends!

As for most questions in business analysis, there isn’t only one answer. Whose job is to create a class diagram depends on the purpose of the class diagram.

First of all, the question implies that there is only one class diagram for a given project: “The Class Diagram”. For the most part, this is not the case. On some projects there may be a multitude of class diagrams while in others there may be none.

Second, the question implies that only one of the person/role on a given project would be task with creating class diagram. This is also not the case! There are many folks (business analyst, systems analysts, developers, etc.) who might have the need to create a class diagram in order to communicate a given concept or to solve a given problem.

So let’s rephrase the question:
“Who would use a class diagram and why?”

The business analyst might chose to create a class diagram in order to model the business domain showing the things of the business (the business domain/industry specific nouns found in the business lingo).

The systems analyst could use a class diagram to develop the logical data model for the system being designed.

The developer may also use a class diagram but for a different purpose: to show the actual classes, interfaces, and types being implemented in a given system.

What is a use case description (specification)?

Chris Adams — Mon, 24 Sep 2007 23:28:00 GMT

A use case description (also known as use case specification) is the textual documentation of an interaction with a business process or IT system in order to achieve something of value (a goal). There are two common formats used for creating use case descriptions. One is the narrative form which describes the interaction in paragraphs, much like telling a story. The other is the dialogue or conversational form, which describes the interaction just as two people might have dialogue, i.e., the actor does A, then the system does B in response.

While it may vary by organization, a use case description typically contains the following:

- Use Case Name

- Brief Description

- Pre-Conditions

- Main Flow of Events

- Alternative Flows

- Exception Flows

- Post Conditions

What is a use case?

Chris Adams — Mon, 24 Sep 2007 23:18:00 GMT

A use case is a representation of an interaction between business worker and a business process or a user and an IT system in order to achieve something of value (a goal). Use cases are the ovals that appear in a use case diagram. A use case and a use case description or specification are different. While use cases represent an interaction (usually with a simple verb-noun phrase) use case descriptions/specifications describe the interaction in detail form.

Use cases can be subdivided into business use cases and system use cases. Business use cases represent the interaction between a business actor and a business process in order to achieve a goal, while system use cases represent the interaction between a system actor, which can be a system user or another system, and an IT system in order to achieve something of value.

Is there anything in RUP that you would change in order to improve the efficiency of the system development process?

Chris Adams — Thu, 20 Sep 2007 22:22:00 GMT

[Be the first to post an answer to this question!]

What is UML?

Chris Adams — Thu, 20 Sep 2007 01:27:00 GMT

UML stands for Unified Modeling Language. UML is an industry standards used to assist analysts and programmers with developing scalable, extendable, maintainable, secure, and robust applications. Large systems tend to be very complex and structure is one way of dealing with complexity. UML provides a common language for analysts and programmers throughout the IT industry to organize and structure complex systems in a way that can be understood by everyone involved. It allows IT professionals to specifiy, visualize, and document models of a software system, both structurally and behaviorally.

Name a few of the industry standards, methodologies, or best practices used by business analysts and systems analysts?

Chris Adams — Thu, 20 Sep 2007 00:57:00 GMT

-UML

-BPMN

-RUP

What are the most relevant UML diagrams for Systems Analysts?

Chris Adams — Thu, 20 Sep 2007 00:49:00 GMT

While opinions may vary based on the role of the Systems Analyst from organization to organization, the following UML diagrams are probably the most predominantly used by Systems Analysts:

-Class Diagram

-Use Case Diagram

-Package Diagram

-Activity Diagram

-Sequence Diagram

-State Machine Diagram

-Communication Diagram

What are the most relevant UML diagrams for Business Analysts?

Chris Adams — Thu, 20 Sep 2007 00:43:00 GMT

While opinions may vary based on the role of the Business Analyst from organization to organization, the following UML diagrams are probably the most predominantly used by Business Analysts:

-Class Diagram

-Use Case Diagram

-Activity Diagram

-Sequence Diagram

Name and describe the different categories of UML diagrams.

Chris Adams — Thu, 20 Sep 2007 00:37:00 GMT

There are 3 categories of UML Diagrams:

Structure Diagrams: Diagrams that model elements of a business domain or system irrespective of time.

Behavior Diagrams: Diagrams that model the functional or behavioral aspects of a system or business process. These diagrams place less emphasis on detailed interactions and focus more on the overall functionality and flow of a business process or system.

Interaction Diagrams: A subset of behavior diagrams, these diagrams place a heavy emphasis on the interactions between object of a business process or system.

--
Chris Adams
LinkedIn Profile